Remarks 



The Office Action mailed April 15, 2009 has been carefully considered. After such 
consideration, independent apparatus Claims 1; 53; 77; and independent method Claims 151; 
152; and 153 have been amended to further clarify the present inventions over the art cited by the 
Office. The amended elements can be found, for example, at page 14, lines 32-33 and page 16, 
lines 16-30. Therefore, no new matter is added by this amendment. Thus, apparatus Claims 1- 
52; 53-76; and 77-150; and corresponding method Claims 151; 152; and 153 remain in the case 
with none of the claims having been allowed. 

The Office Action rejected Claims 1-153 under 35 U.S.C. 1 12(2) as failing to properly 
invoke 35 U.S.C. 1 12(6). The language in the previous amendments has been amended to 
correct this technicality as best understood by the Applicant. 

The Office Action also rejected Claims 1-153 under 35 U.S.C. 101 because the claimed 
invention is directed to non-statutory subject matter. Claims 1-52 and 151-153 recite a method. 
Claims 53-150 recite a system. The Applicant respectfully disagrees and requests 
reconsideration in view of the above amendments (which correct independent Claim 1 to a 
system rather than a method) and the following remarks. 

It is respectfully submitted that the rejection of the Claims in the present application 
under 101 is similar to the fact situation in Ex parte Andreas Mvka and Christina Lindholm 
(Decided: May 13, 2009). In this decision, the Appellants overcame a 101 rejection by 
"communicating" information between a master device and a slave device. The claims at issue 
related to bonding 'slave' devices, such as media capture devices, and instructing the devices to 
communicate captured media files with a specified set of metadata included. 

The Examiner in that case rejected the claims under 101 using the "useful, concrete, and 
tangible result" test. However, the BPAI found that the steps set forth in the claims are 
performed by a master device or a bondable/bonded slave device. The BPAI agreed with the 
Appellants, for example, that the independent claims include "communicating information 
between the master device and the bonded device." Thus, the BPAI found that the claims were 
each tied to a particular machine or apparatus and reversed the 101 rejection. 
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In the present case, the data pulhng component on the at least two invoicers' web sites or 
on web sites of entities working on behalf of the invoicers reads each invoicer's data using the 
data pulling component, packages the invoicer's data and sends the data to the remote customer 
interface in response to customer data requests using the data pulhng component. Thus, it is 
clear that the present claims are tied to a particular machine or apparatus and the 101 rejection 
should be withdrawn. 

The Examiner has again rejected Claims 1-153 as being unpatentable under 35 U.S.C. 
103 by U.S. Patent No. 6,826,542 to Virgin et al. ("Virgin") in view of U.S. Patent No. 
6,493,685 to Ensel ("Ensel"). Reconsideration and allowance is respectfully requested in view 
of the following remarks. 

U.S. Patent No. 6,826,542 to Virgin et al. is a central invoicing system. Customers 
(payors) and invoicers can use the central invoicing system by connecting to it by a network, 
such as the Internet, and using an interaction device, such as a personal computer with web 
browsing software. Customers can create, on the central invoicing system, a list of invoicers 
from whom they wish to receive invoices. The system sends invitations, including a user name 
and password, to the selected invoicers to enroll with the central invoicing system. The system 
provides invoicers with a facility to enroll with the central invoicing system over the Internet. 
Customers can also customize the format of the invoices they are to receive from the selected 
invoicers. 

The central invoicing system of Virgin stores each customer's particular invoicing format 
on a server. The system allows an invoicer to connect to the system through the Internet to 
create invoices. The invoicer can then submit that invoice to the customer through the system. 
The system formats the invoice according to the customer's desired invoice format and transmits 
the invoice to the customer's financial system. Once notified, the customer may access the 
central invoicing system to view, process, and approve the invoice. If the customer approves the 
invoice, the invoice is transmitted to the customer's financial system. However, the invoicing 
system of Virgin does not include a dynamic inbox that allows a customer a choice of which 
invoicers to display in the customer's dynamic inbox. The Examiner states that Ensel teaches a 
djoiamic in-box (col. 8, hnes 14-25 and col. 9, lines 20-40). However, the Apphcants 
respectfully disagree for at least the following reasons. 
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specifically, as best seen in Figure 1 10 of the present application, there is shown a 
schematic representation of the dynamic display portion of an automated electronic invoicing 
and payment consohdation system constructed according to present invention. Remote computer 
440 accesses the portal display web server for enrolling invoicers. Network 710 accesses web 
server, through either Internet, internal LAN, or dialup. Web server 720 at the portal hosts the 
dynamic inbox application. 

The portal Page builder apphcation 730 creates page for display of portal information to 
customer. This application constructs and outputs web html documents for display on the web 
server. It also accepts customer requests for display and navigation through the page and site. 
This application calls the bill summary page builder 740 to create the dynamic inbox section of 
the page for the customer. The portal application 730 passes the customer infDrmation obtained 
by the customer login into the portal site to the bill summary page builder 740. 

Bill summary page builder application 740 constructs the bill summary for the customer 
on the portal's page. The page builder builds the dynamic inbox for a customer upon request by 
first authenticating through the customer authentication application 745 that validates that this is 
a valid customer. It also retrieves the stored security tokens for the customer to pass to the 
invoicer data server 765 in encrypted form through a secure link. The invoicer data server 765 
then confirms the customer's validation information against its customer authentication database 
600. The bill summary page builder also retrieves from the customer authentication application 
745 the hst of invoicers that the customer chooses to display in their dynamic inbox. The bill 
summary page builder then calls the invoicer authentication application 750 to validate the 
invoicers selected by the customer and also retrieves the invoicer URL information for building 
the invoicer links in the dynamic inbox. 

The bill summary page builder passes a series of requests to the invoicer data server 765 
through a secure link for the customer, including security tokens for vahdation, invoicer, and 
accounts, and type of data requested. After vahdating the customer and the invoicer, the invoicer 
data server 765 then returns back the requested data to the bill summary page builder through a 
secure link. 

Invoicer authentication application 750 validates that the invoicers sent fi:om the bill 
summary page builder are valid invoicers by checking against the invoicer authentication 
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database 430. It also retrieves other invoicer information including URLs from the invoicer 
authentication database 430. 

Customer preferences apphcation 760 allows customer to configure the display of web 
pages from the portal. The customer is able to select how and what items they would like to 
have displayed on their page. The customer can also confiRure how bills are displaved for 
dynamic inbox in this apphcation by selecting displav changes based upon certain values. For 
example, the customer could configure the application to change the color of the invoicer line to 
red if the date due has exceeded the current day. This application will store customer's 
preferences and retrieve them upon page display by the customer. 

Database 770 stores customer page preferences. This database is used for storage of 
those preferences and its data is retrieved by the customer preferences application 760 for 
determining the customer's preferences when displaying the page. 

Invoicer data server 765 is responsible for validating the request from the bill summary 
page builder 740 and returning the appropriate data or error message to this application. 

The portal validation application 772 is part of the invoicer data server 765 that first 
validates that portal making the request is a valid portal by checking against the portal 
enrollment database 530. Account validation application 775 is part of the invoicer data server 
765 that validates the customer's account and identification is valid by checking the security 
tokens against the customer authentication database 600. The application decrypts the security 
token and compares this decrypted token with the customer's token stored in the database. 

The Request Translator application 780 is part of the invoicer data server 765 and passes 
the customer's request to the appropriate server for retrieving the necessary data. XML server 
790 retrieves information about the customer's bill data for this account and packages it into an 
XML format that is returned to the invoicer data server 765. It retrieves this information through 
the invoicer summary server application 820 that retrieves this information from the invoicer's 
system either at the time of the request or in a batch mode. 

Graphics Server 800 retrieves information about the customer's bill data for this account 
and packages it into a graphic format (GIF, or other graphic format) and returns it to the invoicer 
data server 765. It retrieves this information through the invoicer summary server application 
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820 that retrieves this information from the invoicer's system either at the time of the request or 
in a batch mode. 

Generic or specific format server 810 retrieves information about the customer's bill data 
for this account and packages it into in specified format. This format can be IFX, OFX, EDI, or 
other specified format and these servers will handle the packaging of this information to be 
passed back to the invoicer data,server 765. It retrieves this information through the invoicer 
summary server apphcation 820 that retrieves this information from the invoicer's system either 
at the time of the request or in a batch mode. 

Invoicer summary server application 820 receives request from the format servers and 
retrieves this invoicer information from the invoicer summary database 830. The invoicer 
summary database is populated by the invoicer either at the time of the request or through batch 
processing. Alternatively, the invoicer summary server could retrieve the information directly 
from the invoicer systems through some interface or specified database stored procedure. 

Database 830 stores invoicer summary information that the invoicer's system either 
populates at the time of the request from the invoicer summary server application or is updated 
on a periodic basis from the invoicer systems. 

Thus, the present inventions provide a dynamic inbox that conveniently allows a 
customer to choose which invoicers are displayed in a dynamic inbox. As the Examiner can 
appreciate from the above detailed description of the Dynamic In-box set forth in the present 
application, the structure set forth at col. 9, lines 20-40 of Ensel can not be considered 
sufficiently enabling to one of ordinary skill in the art to provide a proper 103 rejection and the 
Examiner is respectfully requested to withdraw the rejection. 

The Present Inventions are Not Obvious Over The Cited References 

MPEP Section 2143 points out the KSR Guidelines to be considered in a Section 103 
rejection. Those guidelines have not been met as to the pending claims. 
(A) Combining prior art elements according to known methods to yield predictable resuUs; 

There are no cited prior art elements to combine that would yield predictable results. The 
changes required by the amended claims define elements that offer no benefit to the cited 
references. 
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(B) Simple substitution of one known element for another to obtain predictable results; 

There are no elements being substituted. The distinctions relate to a different element, 
namely that a dynamic inbox adapted to display a list of invoicers that is selectable for display in 
the dynamic inbox by a customer using a remote customer interface for accessing a consolidated 
invoicer interface. The present inventions' dynamic inbox is not relevant to the purposes of the 
cited references. 

(C) Use of known technique to improve similar devices (methods, or products) in the same way; 

The defined limitations would not improve the methods and products of the cited 
references and, in fact, would serve no useful purpose in the cited references. 

(D) Applying a known technique to a known device (method, or product) ready for improvement 
to yield predictable results; 

There are no predictable results in applying the present inventions' features, wherein a 
remote customer interface includes a dynamic inbox adapted to display a list of invoicers that is 
selectable for display in the dynamic inbox by an authorized customer. 

(E) "Obvious to try" - choosing from a finite number of identified, predictable solutions, with a 
reasonable expectation of success; 

There is no basis for making it "obvious to try" including a dynamic inbox adapted to 
display a list of invoicers that is selectable for display in the dynamic inbox by at least one 
customer, since this feature is not relevant to the purpose of the cited references. There are not a 
finite number of identified, predictable solutions relevant to the present inventions. 

(F) Known work in one field of endeavor may prompt variations of it for use in either the same 
field or a different one based on design incentives or other market forces if the variations are 
predictable to one of ordinary skill in the art; 

There is no Icnown work cited by the Examiner that would prompt variations based on 
design incentives or other market forces. The variations are not predictable. 



124865.doc 



33 



(G) Some teaching, suggestion, or motivation in the prior art that would have led one of ordinary 
skill to modify the prior art reference or to combine prior art reference teachings to arrive at the 
claimed inventions. 

The lack of any teaching, suggestion, or motivation in the prior art is discussed in detail 
above. Simply put, the disclosures of the cited references do not include a dynamic inbox 
adapted to display a list of invoicers that is selectable for display in the dynamic inbox by a 
customer and such a dynamic inbox would serve no purpose in the methods and products of the 
cited references. 

The Applicant submits that by this response, he has placed the case in condition for 
immediate allowance and such action is respectfully requested. However, if any issue remains 
unresolved, Applicant's attorney would welcome the opportunity for a telephone interview to 
expedite allowance and issue. 



Respectfully submitted, 




Edward W. Rilee 
Reg. No. 31,869 



MacCord Mason PLLC 
P.O. Box 2974 
Greensboro, NC 27402 
(336) 273-4422 



Date: August 17, 2009 
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